hm, so was this previously writing zeros through to these?

No but previously the constructor always made a copy of the vectors, ref e0d75d7#commitcomment-22968553

were Tridiagonal or SymTridiagonal behaving like that too, or was Bidiagonal the only case of it?

e0d75d7 only changed the behaviour of Bidiagonal. The other ones still have constructors that don't copy: Diagonal, Tridiagonal and SymTridiagonal.

isn't this conversion to Vector what you're trying to make unnecessary?

This is just a fallback for cases like Bidiagonal(::Vector{T}, ::GenericVector{T}), but perhaps the constructor on line 62 should be generalized to promote to the same container type as well, and not just promote the element type? That would make this constructor obsolete.
Currently the promotion is as follows:

Bidiagonal(::Vector{T}, ::GenericVector{S}) ->
Bidiagonal(::Vector{R}, ::GenericVector{R}) ->
Bidiagonal(::Vector{R}, ::Vector{R})

The problem with generalizing the method above was this:

julia> A = rand(3); B = GenericArray(rand(3)); a, b = promote(A,B);

julia> typeof(a)
Array{Float64,1}

julia> typeof(b)
Base.Test.GenericArray{Float64,1}

i.e. they don't promote to the same container type. Hence the current scheme.

Thinking about this a bit more, perhaps we should not promote anything in the constructor here, and instead let the user promote to appropriate types. In that case this:

function Bidiagonal(dv::V, ev::V, uplo::Symbol) where {T,V<:AbstractVector{T}}
    Bidiagonal{T}(dv, ev, char_uplo(uplo))
end

would be the only constructor. The good thing about this is that we don't try to "figure out" what the user wants; instead the user have to be explicit about this. The other good thing with this method is that the vectors in the Bidiagonal will always alias the vectors sent to the constructor. This would then be consistent with the new Diagonal type from #22718 . As this PR currently stands, the vectors will sometimes alias and sometimes not.

We would also have to deprecate methods that did convert, but I still like this better. It is probably not very often you supply two different vector types anyway; and it would be consistent that the vectors always alias, so I will update the PR like that later, unless other people think that’s a bad idea.

or promote in a way consistent with what concatenation would do, since this is sort of like a diagonal concatenation

the aliasing predictability benefits of not promoting at all and making the user pick could also have advantages though - as long as the old methods were deprecated, and the restriction is documented, I think that would also be fine and not trip up too many people

add a bullet for this deprecation in NEWS

Right, updated.

I didn't actually realize diag(A, k) would already give a SparseVector

Yeah, as long as the two arg form is inferable this should be "more correct" since diag(A) in some cases give something else.

which isn't very consistent with it acting like a default argument, but that's a discussion for a different issue

I was thinking this would go in the Deprecated or removed section since the library functionality part of the change is mentioned earlier